The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Software vulnerabilities are weaknesses or flaws in computational logic. As used herein, the term “software” also refers to firmware. When exploited, a vulnerability can facilitate unauthorized access to a computing device, enable an attack to remain undetected, permit unauthorized modification of data, reduce the availability of data, and/or the like. An attempt to exploit or take advantage of a vulnerability is referred to herein as an attack, and a successful attack results in what is hereinafter referred to as a breach.
Often, programs are developed to exploit vulnerabilities. Such programs are referred to herein as exploits. For example, a particular vulnerability affecting Linux kernel versions through 3.14.5 failed to ensure that system calls had two different futex addresses. An exploit known as Towelroot took advantage of this vulnerability to gain root access to Android devices.
Vulnerabilities can be remediated using patches, version upgrades, and/or the like. Due to resource constraints, however, not all vulnerabilities can be remediated at the same time. Thus, remediation of vulnerabilities is typically prioritized according to different levels of risk posed by different vulnerabilities. For example, some vulnerabilities may never have exploits developed for them, and some exploits may never be used in an attack. Accordingly, remediation may be prioritized in the following order: (1) vulnerabilities having exploits that have been used in attacks, (2) vulnerabilities having exploits that have not been used in attacks, and (3) vulnerabilities not having any exploits.
However, waiting for exploits to be developed and for attacks to occur exposes computing assets to a significant amount of risk. Thus, it would be beneficial to be able to predict whether an exploit will be developed for a particular vulnerability and, if so, whether the exploit will be used in an attack.
While each of the drawing figures depicts a particular embodiment for purposes of depicting a clear example, other embodiments may omit, add to, reorder, and/or modify any of the elements shown in the drawing figures. For purposes of depicting clear examples, one or more figures may be described with reference to one or more other figures, but using the particular arrangement depicted in the one or more other figures is not required in other embodiments.